Computer software is designed and developed to solve problems and/or accomplish a particular set of tasks. When computer software is developed for digital computers, the logical objectives to be accomplished by the software are typically determined during the design or planning phase. These logical objectives are often allocated to named parts of the software called procedures, functions, subroutines, etc. (hereinafter called procedures) during the development phase. Each procedure encapsulates one or more of the logical objectives determined for the software during the design phase.
As is known in the art, it is common to display a computer software source code with tools (e.g., editors, code viewers, debuggers, etc.) that display the source code in a linear or monolithic view. The source code (including source code containing multiple procedures) is typically displayed beginning at the top of the source code. A software developer will scroll down through the source code to locate a desired portion of source code (e.g., a procedure). If a developer wishes to focus on a particular procedure within the source code, a search is typically completed using a keyword (e.g., procedure name) within the procedure to locate it within the source code.
There are also tools, however, such as those provided in Visual Basic.RTM. 3.0 by Microsoft Corporation, and the Concurrent C++ Editor described in "Distributed Debugging: An Integrated Approach", by Stephen Lesavich, a 1991 PhD Dissertation from the Illinois Institute of Technology, Chicago, Ill., that parse the source code, extract procedures, and provide ability to view the source code in the procedural view. Viewing source code in a procedural view instead of a linear or monolithic view, makes it easier for a software developer to create and debug code that accomplishes the logical objectives determined for the software.
There are several problems associated with existing methods used to view source code containing multiple procedures using a procedural view. Conditional compilation instructions are often used to define the beginning and ending boundaries of a procedure. Conditional compilation instructions are used as a mechanism to allow a computer language compiler to simultaneously incorporate and exclude different portions of the same source code based on a pre-determined condition. For example, conditional compilation instructions containing two possible ending boundaries for the same procedure have the format:
______________________________________ begin procedure 1 #if VAR 1 do first set of things end procedure 1 #else do second set of things end procedure 1 #endif ______________________________________
In the above example, if the pre-determined conditional compilation variable VAR1 has a value other than zero (i.e., making the #if VAR1 instruction true), the source code instructions representing the `first set of things` is compiled along with the first `end procedure1` instruction. If VAR1 has a value equal to zero (i.e., making the #if VAR1 instruction false, so the #else instruction is executed), the source code instructions for the `second set of things` is compiled along with the second `end procedure1` instruction. A similar sequence of conditional compilation instructions may also be present for the beginning boundary of a procedure. The instructions for the first and second set of things to do in the above example may each provide functionality for a totally unique, and potentially mutually exclusive procedure whose actual functionality is not determined until the source code containing the procedure is actually compiled (e.g., a procedure which is a client in one application, and a server in another).
Conditional compilation causes a problem for many editors, source code viewers, and other tools which provide a procedural view of source code. When a procedure is being developed or debugged, it is necessary to view the whole procedure, including procedure begin/end instructions contained within conditional compilation instructions. Many of the tools which allow source code to be shown in a procedural view typically employ pattern matching processes which look for a single pair of "begin" and "end" instructions or markers for each procedure. However, conditional compilation instructions permit a developer to define more than one begin instruction, and more than one end instruction for a procedure, often resulting in a uneven number of begin/end instructions in the source code.
Conditional compilation instructions make this type of begin/end instruction pair pattern matching difficult, and in many cases make it nearly impossible for existing software development tools to determine what the actual boundaries of a procedure are. As a result, it is difficult to correctly display the whole procedure with tools that provide a procedural view of source code.
In addition, it is common for a software developer to put comment instructions (hereinafter comments) before, after, and within procedures in source code. Comments typically contain a "plain English" description of the procedure functionality and components, and are delineated by special markers (e.g., "//", "/* */", "'", "rem" etc.) Since comments can be put anywhere in and/or around a procedure, it is also difficult to determine which comments are associated with a given procedure in source code, when a procedural view is used. For example, if source code contains the following sequence of lines:
______________________________________ comment 1 procedure one begin procedure one instructions procedure one end comment 2 comment 3 procedure two begin procedure two instructions procedure two end ______________________________________
it is hard to determine which procedure (i.e., procedure one or two) comment 2 is associated with. Most tools which provide a procedural view cannot determine if comment 2 is a comment trailing, but associated with, procedure one, or is a comment preceding but associated with procedure two. Conditional compilation instructions within a procedure containing comments further complicate comment processing in a manner similar to the procedure boundary determinations described above.
In accordance with the present invention, the problems associated with viewing source code in a procedural view are overcome. Procedure boundaries are determined automatically (i.e., without additional input from a user) with a procedure boundary detection method. The procedure boundary detection method, which will be explained in detail below, accurately determines the boundaries of procedures, including the boundaries of procedures which have an unequal number of begin/end instructions (e.g., procedures whose beginning and ending instructions are contained in conditional compilation instructions). The procedure boundary detection method determines procedure boundaries by selecting source code including one or more procedures, searching the source code for the procedures (i.e., searching for procedure begin/end instructions), and automatically (i.e., without further user input) determining the boundaries of the procedures found in the source code by examining the source code instructions which precede/succeed the procedure beginning and ending instructions.
A preferred procedure boundary detection method accurately determines procedure boundaries in a linear search time N from any position within the source code where N is the number of source code instructions in any selected procedure. This is an improvement over other procedure boundary detection methods known in the art which typically require a search time proportionate to M where M is the number of instructions in the entire source code. This is because these methods involve searching all the source code from top-to-bottom or bottom-to-top. However, the M search time boundary detection methods known in the art do not correctly determine the boundaries of procedures with an unequal number of begin/end instructions. The procedure boundary detection method of the present invention also matches comments in and around procedures, to the appropriate procedure based on spacing of the comments. As a result, the proper procedure boundaries, including comments associated with the procedure, are accurately displayed in a procedural view.
The procedure boundary detection method allows a developer to view procedures and their associated comments contained within source code in a procedural view. This makes the creation, development, and debugging of computer software which is divided into a multiple of procedures, easier and more efficient. The procedure boundary detection method also speeds the software development process and helps reduce overall software development and maintenance costs by providing an accurate display of procedures in source code.
The foregoing and other features and advantages of the present invention will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.